As networks continue to grow users are often disconnecting and connecting to the network much more. Wireless communication makes it possible for networks to create themselves spontaneously as devices with the proper protocol enter the area of influence of the network. Several new technological developments like Jini Technology, Java Card™ GSM (Global System for Mobile) smart cards, Java capable cellular phones, and UPI (Universal Resource Locator Programming Interface) addressable servers, when brought together provide an easier way for building and deploying authentication, authorization, and payment infrastructure on networks. Hereafter, authentication is inclusive of all three processes: authentication, authorization, and payment.
Modern secure authentication schemes often require something you have and something you know. Often the something you have is a smart card. One of the problems with deploying smart cards is that they require smart card readers, which add costs and if the reader does not have an integral keypad for PIN (Personal Identification Number) entry they are still vulnerable to data keyboard sniffing. A convergence of the Personal Data Assistant and the cellular phone can provide devices for user authentication with the actual security mechanism hidden from the user. That is, the smart card will be on the circuit board; the user will not be required to insert the smart card like today's credit cards. Removable smart cards will also add another step as data on these devices grow and also because of the desire to have all related data in one place. Currently, some removable smart cards that enable secure computing devices are provided in jewelry form factor.
The following definitions are necessary to fully understand the present invention.
Jini Architecture:
A Jini system is a distributed system federating groups of users and the resources required by those users. A Jini architectural network is a flexible, easily administered tool on which human and computational clients can find resources. Resources can be hardware devices, software programs, or a combination of the two. The system makes the network a more dynamic entity that better reflects the dynamic nature of technology by enabling the ability to add and delete services flexibly.
The Jini system enables users to share services and resources over a network, provides users easy access to resources anywhere on the network while allowing the network location of the user to change, and simplifies the task of building, maintaining, and altering a network of devices, software, and users.
Jini extends the Java application environment from a single virtual machine to a network of machines. The Java application environment provides a good computing platform for distributed computing because both code and data can move from machine to machine. The environment has built-in security that allows the confidence to run code downloaded from another machine. Strong typing in the Java application environment enables identifying the class of an object to be run on a virtual machine even when the object did not originate on that machine. The result is a system in which the network supports a fluid configuration of objects which can move from place to place as needed and can call any part of the network to perform operations.
The Jini architecture exploits these characteristics of the Java application environment in the construction of a distributed system. The Jini architecture adds mechanisms that allow fluidity of all components in a distributed system, extending the easy movement of objects to the entire networked system.
The Jini technology infrastructure provides mechanisms for devices, services, and users to join and detach from a network. Joining into and leaving a Jini system is an easy and natural, often automatic, occurrence. Jini systems are far more dynamic than is possible in some networked groups where configuring a network is a centralized function done by hand.
The Jini system federates computers and computing devices into what appears to the user as a single system. It relies on the existence of a network of reasonable speed connecting those computers and devices. Each Jini technology-enabled device has some memory and processing power. Devices without processing power or memory may be connected to a Jini system, but those devices are controlled by another piece of hardware and/or software, called a proxy, that presents the device to the Jini system and which itself contains both processing power and memory.
The Jini system is Java technology-centered. The ability to dynamically download and run code is central to a number of the features of the Jini architecture. However, the Java technology-centered nature of the Jini architecture depends on the Java application environment rather than on the Java programming language. Any programming language can be supported by a Jini system if it has a compiler that produces compliant bytecodes for the Java programming language.
The Jini architecture is a federated group of devices and software components that function as a single dynamic distributed system. The resulting federation provides the simplicity of access, ease of administration, and support for sharing that are provided by a large monolithic system while retaining the flexibility, uniform response, and control provided by a personal computer or workstation.
The most important concept within the Jini architecture is that of a service. A service is an entity that can be used by a person, a program, or another service. A service may be a computation, storage, a communication channel to another user, a software filter, a hardware device, or another user. Two examples of services are printing a document and personal services. Personal services, for example, may be a matrix that includes data items like: your shoe size, birth date, dining preferences, spending habits, etc (i.e., things that other Jini clients may use to provide the services you may need). The data may also include who may have access to individual items in your personal services matrix.
The Jini technology infrastructure and programming model are built to enable services to be offered and found in the network federation. These services make use of the infrastructure to make calls to each other, to discover each other, and to announce their presence to other services and users.
Services appear programmatically as objects written in the Java programming language, perhaps made up of other objects. A service has an interface which defines the operations that can be requested of that service. Some of these interfaces are intended to be used by programs, while others are intended to be run by the receiver so that the service can interact with a user. The type of the service determines the interfaces that make up that service and also define the set of methods that can be used to access the service. A single service may be implemented by using other services.
Members of a Jini system federate in order to share access to services. A Jini system consists of services that can be collected together for the performance of a particular task. Services may make use of other services, and a client of one service may itself be a service with clients of its own. The dynamic nature of a Jini system enables services to be added or withdrawn from a federation at any time according to demand, need, or the changing requirements of the clients using it.
Services in a Jini system communicate with each other by using a service protocol, which is a set of interfaces written in the Java programming language. The set of such protocols is open ended. The base Jini system defines a small number of such protocols which define critical service interactions.
Services in a Jini environment are found and resolved by a lookup service. The lookup service is the central bootstrapping mechanism for the system and provides the major point of contact between the system and users of the system. In precise terms, a lookup service maps interfaces indicating the functionality provided by a service to sets of objects that implement the service. In addition, descriptive entries associated with a service allow more fine-grained selection of services based on properties understandable to people.
Objects in a lookup service may include other lookup services; this provides hierarchical lookup. Further, a lookup service may contain objects that encapsulate other naming or directory services, providing a way for bridges to be built between a Jini Lookup service and other forms of lookup service. Of course, references to a Jini Lookup service may be placed in these other naming and directory services, providing a means for clients of those services to gain access to a Jini system.
The Jini technology employs a security model based on the twin notions of a principal and an access control list. Jini services are accessed on behalf of some entity—the principal, which generally traces back to a particular user of the system. Services themselves may request access to other services based on the identity of the object that implements the service. Whether access to a service is allowed depends on the contents of an access control list that is associated with the object.
Access to many of the services in the Jini system environment is lease based. A lease is a grant of guaranteed access over a time period. Each lease is negotiated between the user of the service and the provider of the service as part of the service protocol: A service is requested for some period; access is granted for some period, presumably taking the request period into account. If a lease is not renewed before it is freed-either because the resource is no longer needed, the client or network fails, or the lease is not permitted to be renewed-then both the user and the provider of the resource may conclude the resource can be freed.
Leases are either exclusive or non-exclusive. Exclusive leases insure that no one else may take a lease on the resource during the period of the lease; non-exclusive leases allow multiple users to share a resource.
The heart of the Jini system is a trio of protocols called discovery, join, and lookup. A pair of these protocols-discovery/join-occurs when a device is plugged in. Discovery occurs when a service is looking for a lookup service with which to register. Join occurs when a service has located a lookup service and wishes to join it. Lookup occurs when a client or user needs to locate and invoke a service described by its interface type (written in the Java programming language) and possibly, other attributes.
Discovery/join is the process of adding a service to a Jini system. A service provider is the originator of the service—a device or software, for example. First, the service provider locates a lookup service by multicasting a request on the local network for any lookup services to identify themselves. Then, a service object for the service is loaded into the lookup service. This service object contains the Java or similar programming language interface for the service including the methods that users and applications will invoke to execute the service, along with any other descriptive attributes.
Services must be able to find a lookup service; however, a service may delegate the task of finding a lookup service to a third party. A client locates an appropriate service by its type—that is, by its interface written in the Java programming language—along with descriptive attributes which are used in a user interface for the lookup service. The service object is loaded into the client.
The service object's methods may implement a private protocol between itself and the original service provider. Different implementations of the same service interface can use completely different interaction protocols.
The ability to move objects and code from the service provider to the lookup service and from there to the client of the service gives the service provider great freedom in the communication patterns between the service and its clients. This code movement also ensures that the service object held by the client and the service for which it is a proxy are always synchronized, because the service object is supplied by the service itself. The client only knows that it is dealing with an implementation of an interface written in the Java or similar programming language, so the code that implements the interface can do whatever is needed to provide the service. Because this code came originally from the service itself, the code can take advantage of implementation details of the service known only to the code.
The client interacts with a service via a set of interfaces written in the Java or similar programming language. These interfaces define the set of methods that can be used to interact with the service. Programmatic interfaces are identified by the type system of the Java or similar programming language, and services can be found in a lookup service by asking for those that support a particular interface. Finding a service this way ensures that the program looking for the service will know how to use that service, because that use is defined by the set of methods that are defined by the type.
Programmatic interfaces may be implemented either as RMI (Remote Methods Invocation) references to the remote object that implements the service, as a local computation that provide all of the service locally, or as some combination. Such combinations, called smart proxies, implement some of the functions of a service locally and the remainder through remote calls to a centralized implementation of the service.
A user interface can also be stored in the lookup service as an attribute of a registered service. A user interface stored in the lookup service by a Jini service is an implementation that allows the service to be directly manipulated by a user of the system.
In effect, a user interface for a service is a specialized form of the service interface that enables a program, such as a browser, to step out of the way and let the human user interact directly with a service.
In situations where no lookup service can be found, a client could use a technique called peer lookup instead. In such situations, the client can send out the same identification packet used by a lookup service to request service providers to register. Service providers will then attempt to register with the client as though it were a lookup service. The client can select those services it needs from the registration requests it receives in response and drop or refuse the rest.
From the service client's point of view, there is no distinction between services that are implemented by objects on a different machine, services that are downloaded into the local address space, and services that are implemented in hardware. All of these services will appear to be available on the network, will appear to be objects written in the Java or similar programming language, and, only as far as correct functioning is concerned, one kind of implementation could be replaced by another kind of implementation without change or knowledge by the client (note that security permissions must be properly granted).
Java Remote Method Invocation (RMI):
Communication between services can be accomplished using Java Remote Method Invocation (RMI). The infrastructure to support communication between services is not itself a service that is discovered and used but is, rather, a part of the Jini technology infrastructure. RMI provides mechanisms to find, activate, and garbage collect object groups.
Fundamentally, RMI is a Java-programming-language-enabled extension to traditional remote procedure call mechanisms. RMI allows not only data to be passed from object to object around the network but full objects, including code. Much of the simplicity of the Jini system is enabled by this ability to move code around the network in a form that is encapsulated as an object.
Short Message Service
SMS is a service for sending messages of up to 160 characters to mobile phones that use Global System for Mobile (GSM) communication. SMS messages can be transmitted to digital phones from a Web equipped with PC link or from one digital phone to another.
URL Programming Interface (UPI)
Developing consistent, reliable Web applications that interface to different devices-such as home networks, home automation systems, or real-time process control devices—can be vastly simplified by treating devices as URLS. The URL programming interface (UPI) effectively provides a set of URLs for a device that are available to any application capable of performing the HTTP (HyperText Transfer Protocol.) HTTP has become so universal that in college computer courses students are often given as an assignment the creation of an HTTP stack. This trend is due to the growing interest in connecting devices to the Internet. Sun Microsystems Laboratories has used the Java™ language to develop a technology that allows users to deploy a very small HTTP stacks, with a core of less than 100 KB. However, the claimed invention can be practiced using any computer programming language.
These small HTTP servers can be run on any embedded device or used as application servers that are similar to traditional Web servers. Such minimal servers provide an integrated presentation and service layer for a device. Because a Web server answers URL requests, universal access to devices from any Internet node is achieved. UPI provides an interface to allow applications, including web applications, to access any device as if the device is a file resident on a web server, if the device can perform the HTTP protocol.
The UPI architecture, at its core, consists of a series of handlers that are similar to servlets, but have fewer features. These handlers are mapped to incoming URL requests. This allows the UPI function on very small devices, such as a TINI board. The UPI supplies handlers for web services such as file service and CGI script execution. Application developers can develop handlers for Internet aware devices (IADs) simply by coding a few required methods, such as init and respond, along with code that understands the applicable device grammar.